A substantial number of databases in use are relational databases. A relational database models the world in terms of relational tables. For example, a relational table FRIENDS may be used to model persons who are friends.,Each row in the relational table FRIENDS represents one friend.
Each column of a relational table can represent a characteristic of a friend. Assume one column of the relational table FRIENDS is NAME, and another is SOCIAL SECURITY NUMBER. One row in FRIENDS contains the value of “John Doe” for the NAME column and the value of “999-99-9999” for the SOCIAL SECURITY NUMBER column.
In an object-relational database, the world can be modeled using a type system fundamentally based on object types. An object type is associated with one or more attributes and zero or more methods. Instances of object types are known as “objects”. Each object contains values for its attributes. The values of the attributes are collectively referred to as the object's state. Each object that is an instance of a particular object type has the same attributes. The methods associated with an object (i.e. methods associated with the object type of the object) operate upon the state of an object.
Object-relational databases contain object tables, which are tables that contain objects. Each object in an object table belongs to the same object type. More than one table may contain objects of a particular object type. For example, the tables FRIENDS and EMPLOYEES may both contain objects of the object type PERSON. Each row of data in a table stores the state of an object. Each column of an object table corresponds to an attribute of the objects contained in the object table.
For example, PERSON may define several attributes for objects which represent persons. Assume one attribute is NAME and another is SOCIAL SECURITY NUMBER. Further assume that object table EMPLOYEE contains objects belonging to PERSON. One column in EMPLOYEE corresponds to the NAME attribute, another column corresponds to the SOCIAL SECURITY NUMBER attribute.
Each row in EMPLOYEE contains data about one object. One row, for example, contains data for the object representing one employee with a NAME value of John Doe and having a SOCIAL SECURITY NUMBER value of “999-99-9999”. One column for the row contains the value for the NAME attribute, and another column contains the value for the SOCIAL SECURITY NUMBER attribute.
Object-relational databases offer many advantageous features not offered by relational data tables. One such feature is the ability to create multiple tables with identical columns without having to create, for each table, a separate set of identical definitions for the columns. For example, it may be desirable to create two tables with identical columns, each having a NAME column and a SOCIAL SECURITY NUMBER column. In an object-relational database, the creation of these tables can be achieved by defining one object type, such as the PERSON, having the two attributes NAME and SOCIAL SECURITY NUMBER. Then two object tables, FRIENDS and EMPLOYEE, can be defined as tables having objects belonging to PERSON. It is only necessary to define the columns (i.e. attributes) of FRIENDS and EMPLOYEE once.
One the other hand, creating two tables analogous to the above two tables using a relational database requires two separately stored table definitions, each having their own set of column definitions. For example, to create the FRIENDS table requires one table definition, and to create the EMPLOYEE table requires another. The FRIENDS table definition contains a column definition for NAME and for SOCIAL SECURITY. The table EMPLOYEES requires another table definition identical to the table definition for FRIENDS. It is thus necessary to define each column twice.
Another feature is that attributes of an object may be collection data types such as nested tables or varrays (variable length arrays). These data types enable the modeling of one to many relationships within one object table. For example, an object type can represent a person, a children attribute (of the object type) can be a collection data type which may represent the one or more children of the person.
On the other hand, to model the parent-child relationship in a relational database requires at least two relational tables. One to model persons, another to model the parent-child relationships. The relational table that models the parent-child relationships would have one column identifying the person who is the parent and another column identify a person who is a child of the parent. A row would exist for each child, each row having a value in the parent column identifying the parent and a value in the child column identifying the child.
Another advantage offered by an object-relational database is that data may be modeled in the same manner as data is modeled in client-side applications written in object oriented languages. For example, C++, an object oriented language, models data using a type system based on object types (i.e. classes). Such applications can receive data from a object-relational database in form of objects having the same data structure as object types used by the application software. On the other hand, when receiving data from a relational database, the data received is mapped and translated into the attributes of objects used by the application. This mapping and translation not only requires more work by the computer system at run-time, but also requires more work by developers of application software to develop code for mapping and translating.
Another advantage offered by object-relational databases is that an object id is associated with each object in the database. The object id uniquely identifies an object relative to all the objects in the database system, including objects belonging to a different object type and contained in different object tables. For example, assume that in addition to the FRIENDS and EMPLOYEE object tables, which contain objects belonging to PERSON, a database contains object tables DEPARTMENTS and EMPLOYEE POSITIONS. Objects in DEPARTMENTS belong to the ORGANIZATION object type, and objects in EMPLOYEE POSITIONS belong to the JOBS object type.
The object id associated with the object in EMPLOYEE representing John Doe is unique among object ids of objects of the same object type in other object tables, such as FRIENDS. Furthermore, the object id is unique among all the object ids associated with any object belonging to any object type, such as the objects in object tables DEPARTMENTS and EMPLOYEE POSITIONS.
Most conventional databases systems in use are relational databases. For many users of these databases who seek the advantages of object-relational databases, it is desirable to operate upon the existing data in the relational database as if the data where objects from a database.
Conventional database systems do not provide a mechanism for operating upon relational data as if the data where objects from a database because conventional systems model data using a different manner of abstraction than object-relational systems. More specifically, conventional database systems (i.e. relational databases) are adapted to model entities in terms of rows and columns in a table that relate to each other, not as objects that belong to an object type, or are collections of or references to other objects.
A conventional approach for working around the lack of a mechanism for operating upon relational data as if it where objects is the conversion approach. In the conversion approach, the data existing in relational databases is converted and transferred to object tables in an object-relational database.
Because of the problems inherent in the conversion approach, many users of relational databases are either postponing the conversion of their relational databases to object-relational databases, or are gradually migrating to object-relational databases. Users that are gradually migrating incrementally convert only portions of their relational database. The reasons users are converting to object-relational databases in this manner is that completely converting one entire database to another database is usually a very expensive and risky undertaking. For many users, such as organizations that have been using a relational database for many years, completely converting an entire database often exceeds available monetary and personnel resources. The attendant risk of losing data in a database during a complete conversion, even temporarily, are often too high to undertake.
Based on the foregoing, it desirable to provide a mechanism which permits users to treat data stored in relational databases as data from an object-relational database. It is further desirable to provide a method that allows the users of relational databases to enjoy the advantages of object-relational databases without having to convert their existing relational database to an object-relational database.